Mobile phones have become ubiquitous in the US over the past decade. SMS (short message service), popularly known as “text messaging”, has grown in popularity over the past several years to become one of the most widely used mobile phone features. Projections estimate that 80 billion SMS messages will be sent per month in 2008. As a result, services have begun to emerge which seek to provide useful concise information to mobile phone users by SMS (and other media), such as weather forecasts, sports scores, etc. Since many mobile phones are limited by small displays and restricted input mechanisms, a method of quickly and easily locating concise content is of interest to mobile phone users and hence to content providers seeking to enter and serve the mobile market.
One approach to address this need is to provide services for end users by creating repositories of useful information and making that information available via some kind of search engine. Such a model has been adopted by the SMS service of 4info.net, under the short code $INFO (44636), the SMS service of GOOGLE®, under the short code GOOGLE (466453), and others. For example, the text message request “weather 90210” sent to the 4info.net short code 4INFO may return a weather forecast for the zip code 90210. The primary limitation of this approach is that it requires the service provider to provide all possible information in which an end user might be interested. However, if an end user wishes to find a review of a particular vintage of wine and neither 4info.net nor GOOGLE® offer wine review, the user will be disappointed. The widespread usage of mobile phones across all demographics and the vast variety of information that has been made available on the internet suggest that this approach can only be a partial solution.
A second approach to address this need allows content providers to offer content via mobile media. This is the approach adopted by, e.g., Mobivity.com, which allows content providers to reserve SMS “keywords” under the Mobivity.com “shared” short code 95495. For example, a news organization may reserve the keyword “news” and return breaking news headlines in response to the text message request “news” sent to the short code 95495. There are several limitations of this approach. First, there is no method for searching for content across the various shared short codes and no way for end users to search for short codes using their mobile devices. For example, wine reviews may be offered on one shared short code and breaking news headlines on another. The user would be required to remember which is which, if they could even find the shared short codes in the first place. Next, as more and more content becomes available, the logical organization of content under a shared short code becomes more and more difficult, especially as different content providers begin to offer similar types of content. For example, if a news organization was to reserve the keyword “cnn”, the end user would reasonably expect that “cnn” refers to the news organization CNN®, when, in fact, it might refer to some other news organization. Should CNN reserve the keyword “cnn,” the keyword “news,” or some other keyword? Next, shared short codes make no provision for allowing multiple authorship of content. Shared short code services can provide a single keyword to a large organization such as a university but present no mechanism for allowing the tens of thousands of students, faculty, and staff of the university to make their content available under the university keyword. Finally, this approach typically treats different media such as SMS and voice independently, requiring the content provider to prepare their content for each medium individually, by entirely unrelated mechanisms.
Similar issues present themselves in the area of mobile payment systems, such as those offered by OBOPAY™ and PAYPAL®, and the GILBARCO® RFID technology. These payment systems typically allow for payments to be sent either directly to the mobile phone carrier (“Premium Billing”) or from one mobile phone user to the account of another mobile phone user or a merchant.
For these payment systems, much of the related art is focused on identifying a payee via a single identifier. For example, PAYPAL® Mobile allows any user to request money from any other user by SMS with the syntax “get x from y”, where x is an amount and y is a phone number or email address. Sending the text message “get 5 from 4085552388” to the short code PAYPAL (729725) would send a request for $5.00 to the phone number 408-555-2388 via the PAYPAL® payment system. Other related art allows for mobile payments to be requested from or directed to a user specified by a word identifying an account. For example, a payment request by SMS might read “gpay Starbucks357 3.50”. In this example, the payee is identified by the word “Starbucks357,” and the amount to be paid is $3.50.
One of the main problems with existing payment systems such as PAYPAL® Mobile or OBOPAY arises in the field of mobile commerce (“m-commerce”). In particular, larger organizations such as the STARBUCKS chain of cafes might hope to identify each store with an identifier such as “starbucksXXX,” where XXX is the store number. But who has authority over the “starbucks” identifiers? The related art provides no clear mechanism for assigning and managing ownership of these identifiers with STARBUCKS® and STARBUCKS® franchise cafes or for presenting someone unrelated to STARBUCKS® from reserving “starbucksYYY,” where YYY is a non-reserved (or as yet non-existent) STARBUCKS® store. Does the identifier “amazon” refer to the on-line merchant AMAZON.COM® or to some other merchant? Does the identifier “buy” refer to the on-line merchant Buy.com or to some other merchant? Here the problem is very similar to the ambiguity regarding ownership of the keywords “cnn” and “news” described previously.
A second problem with the existing methods as they relate to m-commerce arises from the fact that they make no provision for associating a payment with a particular transaction, for example at a point-of-sale location. For example, a particular STARBUCKS® franchise might want to allow users to text in a payment for an order which has been entered at cash register. However, there is no a priori connection between the order on the cash register and the payment sent in by the user. Hence, the current methods address solely the question of sending money, instead of offering a more comprehensive solution for selling products.
A third problem of current methods as they relate to m-commerce is the need to disclose personal information such as a phone number, email address, or account name when requesting or sending a payment. For example in order to allow a business to request a payment from a user using the PAYPAL® system (e.g., if an order is registered at a cash register), the user would be required to disclose their phone number so that the business could send the request to that user.
Finally, the existing methods as they relate to m-commerce are typically designed to be used person to person and often do not provide an integrated means for a computer (e.g. a cash register) to request or receive payment from a mobile user for a particular transaction.
A separate though related problem in the prior art arises in the field of person-to-person communication. Current person-to-person mobile phone communication, including text messaging and voice, require that a person divulge their mobile phone number to other mobile phone users. While this is acceptable in some cases, it becomes unacceptable if a user wishes to allow a broader audience to contact them on their mobile phone, since no method exists to “revoke” or “un-publicize” a phone number that has been given out (e.g. on a website on the internet). Existing mobile phone person-to-person communication is extremely limited in its provisions for managing permissions for incoming messages or calls. In addition, a mobile phone user may maintain several distinct identities (such as different accounts at MYSPACE® and FACEBOOK®). The prior art makes no provision for carrying these different identities over to mobile phone communication. Finally, mobile phone communication, and text messaging in particular, provide no built-in mechanism for one-to-many and many-to-many messaging, and require custom and proprietary solutions such as the service offered by Twitter.com. The problem with services such as TWITTER™ is that they do not allow a content provider to provide a solution branded to the content provider. For example, Twitter makes no provision for allowing MYSPACE® users to broadcast messages to other MYSPACE® users using their myspace.com accounts.
These problems in the prior art suggest the need for a general, flexible, and standardized method and system which allows anyone with an internet domain name to disseminate content to mobile phone users.
Accordingly, the need remains for more versatile methods for searching for and disseminating information by mobile phones, and for providing means for conducting financial transactions using mobile phones, to address the needs of the ever growing number of mobile phone users who rely on their phones for more than merely voice communication.